During the past thirty-five years, advancements in computer hardware and programming methodologies have fuelled the development of increasingly useful and complex computer-based tools for automating business processes. Currently, both custom-built and commodity computer programs are pervasive in both small and large businesses. Computer programs manage information, including inventory control data, employee data, customer data, and financial data. Computer programs also manage business transactions, such as airline reservation systems and automated order entry, and may even provide a large portion of the business interface between a business and people who interact with the business, such as the web pages of an Internet-based business or automated telephone order-entry systems.
Computer programs, whether used internally within a business, used as a portion of an interface between the business and customers or suppliers, used for supporting general computational tasks, used for conducting scientific analyses or data processing, or for many other reasons, can be considered to be transaction processing systems. For example, an airline reservation system processes flight schedule requests, seat availability requests, and reservation requests. As another example, an order entry system may process submitted order forms. As still another example, an operating system may process an internally generated request to read a block of data from a mass storage device. Transactions are generally defined to have a starting point, often corresponding to the input of data into the computer system, and an ending point corresponding to the completion of a set of related activities, or functions, that together comprise a logical operation. For example, in an airline reservation system, a reservation request transaction may be defined to start with a travel agent inputting, through a graphical user interface ("GUI"), a combination of keystrokes or mouse clicks that indicate to the airline reservation system the beginning of a request for reservation of one or more seats on a future flight. Starting from the initial input by the travel agent, the airline reservation system conducts numerous related operations in order to make a reservation, and finally displays to the GUI an indication that the reservation has been successfully completed, a logical point to define as the ending point of the transaction. The related set of operations conducted by the airline reservation system in order to carry out the transaction may include solicitation and processing of additional input information, such as the customer's name, time of travel, etc., searching a database, based on the input information, for stored data representing the desired flight, checking whether the requested number of seats are available, and updating the stored data to reflect the reservation. The processing of a single transaction by a computer program may involve execution of hundreds or thousands of software routines and millions of computer instructions.
A transaction is the execution of a particular group of instructions by a computer program that have an identifiable effect on some aspect of the environment in which the computer program is running. While many logical transactions that may be defined in the context of a business application program may correspond to business transactions having certain well-known data integrity properties, many other logical transaction are unrelated to business transactions. For example, the detection of a hardware event within a computer system by an operating system and handling of the detected event through one or more subroutine calls may constitute a logical transaction within the context of an operating system program.
Computer programs are continuously subjected to monitoring of various parameters and are regularly refined and redeveloped in accordance with the results of the monitoring. One important parameter is the response time with which a computer program processes a given type of transaction, or, in other words, the time between the start of the transaction and the end of the transaction. Various types of response times may be measured. For example, the total wall clock time of the transaction is often a useful parameter for efficiency studies. The difference of the wall clock time of the transaction and that period of time within the transaction during which the computer program waits for user input may, in some cases, be a more useful parameter. Various statistical measurements of response times, including the variance and standard deviations of different types of response times may also be useful. Another useful parameter is a count of the number of times a particular transaction occurs, and, in some cases, an indication of whether a particular transaction does or does not occur. Such information may allow the usage of various software components to be monitored.
There are a number of different approaches for measuring the different types of response times. Manual methods may involve human observers recording response times using a stopwatch, pencil, and paper. In certain specific types of computer programs, notably database management systems, partially and fully automated techniques may be employed in order to collect large amounts of performance data and efficiently process those large amounts of performance data. These semi-automated and fully automated methods rely on incorporating data collection functionality into computer programs. A standard for instrumenting computer programs for automatic collection of response time data, called the Application Response Measurement ("ARM") interface, has been developed. The ARM interface is an application programming interface ("API") comprising a set of functions that can be called from within a computer program. Using the ARM API, functions can be called to identify the starting and ending points of transactions and to measure the response times associated with execution or processing of each transaction. Thus, the ARM API is a high-level programming interface, and the functions within that interface are incorporated within the high-level programming language description of a computer program in order to instrument the computer program for subsequent performance monitoring. Additional APIs for monitoring computer programs include the Simple Network Management Protocol ("SNMP") API and the Remote Management ("RMON") API.
The approach represented by the ARM API has many deficiencies. Specific deficiencies of the ARM API include a flat name space for transactions and a requirement that a computer program have a single starting and stopping point with respect to the ARM API. Unfortunately, modem computer programs tend to be extremely large, complex systems developed by large, hierarchically-ordered teams of software developers and engineers. In such a development environment, a flat name space for transaction names becomes a difficult problem, requiring a coordinated effort for partitioning the flat name space among the various groups and subgroups of developers and engineers. Because various groups of developers and engineers may work more or less independently on portions of a computer program, the single starting point and stopping point requirement of the ARM API may introduce additional coordination problems when separately developed portions of a computer program are merged together.
There are more fundamental problems with the instrumentation approach represented by the ARM API. Generally, developers and engineers are concerned with the functionality and correctness of that portion of the API that they develop. They may often lack a broad perspective on the computer program that would enable them to both appropriately and meaningfully define transactions and to correctly instrument the portion of the computer program that they are developing in order to collect response time data for transactions. Even having such a perspective, it is a notoriously difficult, if not impossible, task to anticipate and instrument potentially useful transaction in advance of using a computer program. Quite often, the need for monitoring a particular logical transaction may only be apparent after a problem is later discovered. Furthermore, source code tends to be dynamic and unstable. Large computer programs are constantly refined, patched, and otherwise altered in response to error reports, functionality requests, and efficiency monitoring. Even if reasonable ARM API function calls are inserted into an initial version of a large computer program, they may quickly become sterile or inoperative due to modifications and reorganizations of the computer program unless great effort is made to modify the ARM API calls along with modifications of the computer program source code.
A potentially greater problem is that, in a complex and large computer program, it may be very difficult to ascertain target locations within the source code of a computer program in which to insert ARM instrumentation. Frequently, an outside observer's definitions of starting and ending points of transactions, based on observing the interface between human users and a running computer program do not closely correspond to logical entry points within the computer program. For example, an observer of a computer program may define the starting point of an airline reservation transaction to be the point at which a travel agent enters input to a GUI, but, in the running computer program, a large number of generalized GUI and operating system routines, called during processing of many different types of transactions, may precede a first recognizable call to a computer program transaction processing routine logically corresponding to the transaction. In systems comprising a number of asynchronously executing tasks or programs, the logical starting point of a transaction, as determined by an outside observer, may not consistently correspond to execution of a particular instruction or routine within one of the tasks or programs, but may instead vary depending on the state of the entire computer system. In general, it is an extremely difficult problem to identify instrumentation points corresponding to conceptual transactions. It is a difficult problem during development of a computer program, and an even more difficult problem after the computer program has been developed.
Another problem with the approach to instrumentation represented by the ARM API is that the approach relies on the ability of a developer or performance analyst to access, modify, and recompile the source code of a computer program. However, there are many cases where only an executable computer program, or, in other words, a machine code version of a computer program, is available. For example, a business may have obtained the computer program from a third-party software vendor which has neither instrumented the computer program at the source code level nor provides access to the source code of the computer program.
Another problem with the performance monitoring approach represented by the ARM API is that meaningful conceptualization of transactions often cannot occur prior to extended use of a computer program within a business. Moreover, the environment within a given business may change over time, requiring a re-conceptualization of transactions to correspond to new uses of a computer program in the changed environment. In such cases, it is difficult to foresee possible conceptualizations of transactions during development of a computer program, thus requiring difficult and expensive re-instrumentation of the source code of the computer program. As a practical matter, even within single organizations, efficiency experts and monitors may not have access to the source code of a computer program which they are attempting to analyze.
Still another problem with the performance monitoring approach represented by the ARM API is that, despite monitoring instrumentation present within a computer program, monitored events may fail to be reported. For example, a computer program may be instrumented with ARM API calls, but the environment in which monitoring occurs is configured to receive and respond to SNMP or RMON calls.
Thus, computer program developers, computer program vendors, business organizations that use computer programs, and efficiency and response time monitoring analysts and technicians have all recognized a need for a method and system for determining instrumentation targets within computer programs for the collection of data related to various efficiency parameters, including response times, with respect to one or more logical or conceptual transactions carried out by the computer program.